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ABSTRACT 

Historically, the Mission Operations System 
(MOS) for a space mission has been designed 
last because it is needed last. This has usually 
meant that the ground system must adjust to the 
flight vehicle design, sometimes at a signifi- 
cant cost. As newer missions have increasingly 
longer flight operations lifetimes, the MOS 
becomes proportionally more difficult and more 
resource-consuming. We can no longer afford to 
design the MOS last. The MOS concept may 
well drive the spacecraft, instrument and 
mission designs, as well as the ground system. 
This paper presents a method to help avoid 
these difficulties, responding to the changing 
nature of mission operations. It is this paper's 
thesis that proper development and use of an 
Operations Concept document results in a 
combined flight and ground system design 
yielding enhanced operability and producing 
increased flexibility for less cost. 

Key Words: Operations concept, mission 
operations, mission control, operational 
requirements, program phases. 

1. INTRODUCTION 

For most missions, beginning the design of the 
Mission Operations System (MOS) occurs only 
after the spacecraft and mission design are well 
established. It is difficult for a project to 
consider operational issues that impact the 
program several years in the future when 
attention is focused on an immediate spacecraft 
design or fabrication problem. When early 
decisions impacting the ground system are made 
by spacecraft, instrument or mission designers 
without input from MOS designers, difficulties 
in MOS design and implementation arise. As a 
result, costly solutions are sometimes necessary. 
An example of this was the way telemetry from 
the Viking lander experiments was packaged 


into different sized, independent data frames 
rather than packetized into a master frame. 
The seismometry frame was even variable in 
length. The signature of a marsquake could be 
adequately captured only by a high sampling 
rate, therefore the seismology data frame was 
designed with the unique capability to expand 
to a larger number of bytes if a quake were to 
trigger the instrument. This innovative idea 
may have served the experiment well during 
operations, but the design of the telemetry 
frame synchronization process on the ground 
was made unnecessarily complicated because of 
variable length data frames. 

With recent concerted emphasis on reducing the 
cost of space programs, the contribution due to 
designing and building the MOS has to be 
considered along with that of designing and 
building the spacecraft. James S. Martin, 
NASA consultant and former Viking Project 
manager has said, "As more and more missions 
are planned to have flight operations lifetimes 
measured in years, even tens of years, the MOS 
becomes an increasingly more difficult, more 
costly, and more human resource limited 
process. No longer can we afford to design the 
MOS last. In fact, the MOS concept may well 
drive the spacecraft design, the science 
instrument design, and the ground system." 
(From the Foreword to Ref. 1 ) 

There has been recent progress toward involv- 
ing the MOS designers in the process of space- 
craft and mission design from the beginning. 
This paper describes how a key document, the 
Operations Concept, can assist this process. 
Proper development and use of the Operations 
Concept can result in the designs of the 
combined flight and ground system yielding 
enhanced operability, thereby producing 
increased flexibility for less cost. Discussion of 
the Operations Concept is best made in the 
context of standard program phases, reviews 
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and documentation. However, since these vary 
between NASA centers, the following section 
will define the context for this paper. 

2. PROGRAM PHASES AND REVIEWS. 

The four phases of a program's life cycle are: 

(1) system planning, which comprises feasibil- 
ity analysis, concept development, require- 
ments definition, and the development of a 
system acquisition plan; (2) system develop- 
ment, which includes requirements analysis, 
concept evaluation, preliminary and detailed 
design, implementation, and test activities 
through acceptance testing; (3) integration and 
test, which encompasses the integration of 
systems into the overall MOS and complete 
testing of the integrated systems against all 
the specified requirements; and (4) system 
operations, which consists of flight operations 
support, beginning with launch operations. 

In spite of the extra work they cause for the 
system designers, formal reviews of the 
progress of the project before a board of experts 
are essential to resultant design excellence. A 
series of reviews should be held, independently 
for the spacecraft and for the MOS. Figure 1 
illustrates the timing of various reviews with 
respect to the program phases. During the 
System Planning phase, there should be a 
Preliminary Requirements Review (PRR) after 
the initial requirements definition is complete, 
to assess whether or not the requirements are 
well defined. Historically, more projects have 
gotten into serious difficulties due to incomplete 
or ambiguously defined requirements than any 


other cause. A Preliminary Concept Review 
(PCR) is recommended after the full system 
operations concept is developed. 

During the System Development phase, a 
System Requirements Review (SRR) and the 
resolution of action items that follow will 
finalize the requirements and evaluate readi- 
ness for design to begin. After preliminary 
system design is complete, a Preliminary 
Design Review (PDR) is held. The preliminary 
design should be approved before detailed 
design can begin. When the design is complete, 
the Critical Design Review (CDR) is the mile- 
stone preceeding procurement of hardware and 
start of actual implementation. In practice, 
multiple CDRs are usually held for various 
components of the system, due to the additional 
detail and differing review board expertise. 
Unfortunately, many times the design begins 
before the requirements are finalized, the 
project bowing to time and schedule pressure. A 
well developed concept of operations will help 
definitize the requirements early. Minimizing 
the amount of design accomplished before 
finalizing requirements lowers the ultimate 
cost of the system by eliminating redesign. 

During the Integration and Test phase, there 
are many reviews of specific activities to ensure 
the implementation and testing is proceeding 
according to plan. MOS components, consisting 
of both hardware and software, are increment- 
ally delivered after each has completed its 
user acceptance testing. However, when the 
fully developed MOS ground system is ready to 
be delivered, an Acceptance Test Review (ATR) 
is held. The ATR reviews 
the testing against the 
original requirements and 
against the operations 
concept. Once all MOS 
subsystems are delivered 
and the flight operations 
team is selected and 
trained, the Operations 
Readiness Review (ORR) 
is held to verify that the 
entire MOS, including the 
people who will operate 
it, is ready for operations 
to begin. 
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Figure 1 - Program Phases and Reviews 
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For small projects where costs are severely 
limited and the complexity of flight 
components and ground systems are not as great, 
the reviews may also be less expansive in scope. 
(As an example, the preliminary concept may 
be reviewed at the same time as the prelim- 
inary requirements, effectively combining the 
PRR and PCR.) Although some reviews may be 
combined, it is important not to omit the actual 
step from the process, for the efficiency of the 
resulting design depends on orderly execution of 
the design and implementation process. 

3. OPERATIONS CONCEPT. 

An Operations Concept is an orderly collection 
of user-oriented ideas as to how the operations 
system should function to satisfy the mission 
and experiment objectives. Although the 
concept can exist without being documented, a 
written version ensures uniform dissemination 
of the concept. The assumption here is that the 
Operations Concept is a summary document 
describing the collection of ideas that form the 
concept. 

The Operations Concept is an evolving docu- 
ment, with a purpose and function that changes 
with the program phases. Its initial and most 
important function is that it (1) drives the 
program design toward one that will satisfy 
the mission and experiment objectives. Written 
early in the system planning phase, this initial 
version establishes and clarifies the intended 
operational approaches. As the design of the 
operations system is developed, the Operations 
Concept (2) guides the design engineers by 
shaping the definition of system requirements 
and keeping the focus on system operability. 
With additions and configuration-controlled 
revisions as necessary, the Operations Concept, 
at the end of the design phase, (3) becomes a 
summary description of the design, illustrating 
the way the operations system will be used to 
conduct mission operations. The objectives of 
the Operations Concept and its uses are indicat- 
ed by the following nine items, each allocated 
to one of the above three document purposes. 

As a design-driving document, the Ops Concept: 

1. Summarizes the primary objectives and 
constraints for both the mission and experi- 
ments. These basic goals are established by the 
project scientists and mission planners and 


become an input to the system planning phase. 

2. Documents early the intended 
operational approaches. Basic operational 
philosophy delineated early in the planning 
phase will simplify subsequent tasks and 
establish design requirements. 

3. Defines how users will operate and 
maintain the system. The domain of user 
activities is defined. System operations, 
system maintenance and required institutional 
support are all addressed early enough to 
influence the design requirements. 

As a design-guiding document, the Ops Concept: 

4. Becomes the unifying document for the 
requirements analysis and design phases. By 
clearly defining the operational use of the 
system, it serves as a reference for designers, 
communicating the operations strategies to 
project personnel as system definition and 
design proceed. Systems engineers will consult 
it for guidance to ensure the system design will 
satisfy the operator’s requirements. It also 
provides a test bed where design issues can be 
raised and resolved. 

5. Clarifies operational interfaces early. 

It identifies operations interfaces early enough 
in the program to ensure a common understand- 
ing and sufficient definition, resulting in a more 
efficient implementation. Interface identifica- 
tion also defines the environment for the 
integration test program by specifying which 
operational components must "play together." 

6. Provides a framework for trade and cost 
studies. By defining and prioritizing necessary 
system operational features, the operations 
concept will provide criteria for evaluating 
trade study and cost options. 

As a design-description document, the 
Operations Concept: 

7. Provides input for generation of plans 
and procedures. It supplies information for 
various operations plans such as the Mission 
Data Plan (which describes the handling plan 
for downlinked information) and the 
Experiment Operations Plan (which explains 
how the experimenters will operate their 
instruments). It also provides input for 
generation of team operations plans and 
subsequent team activity procedures. 

8. Supplies test objectives for system 
integration tests. This will ensure that the 
testing will prove the mission concept and that 
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the design will meet established requirements. 

9. Summarizes intended mission operations. 
It always remains a concise, readable summary 
of the purpose and intended operation of the 
mission at any time during any phase, for 
either external or internal interests. It is 
required reading for new personnel and a 
valuable source of operations training material. 

The initial version of the Operations Concept is 
written after only the rudimentary mission 
objectives have been determined, and in fact 
must be formed in parallel with those early 
mission concepts. As illustrated by Figure 2, it 
is generated from conceptual ideas of how the 
system will be operationally used to satisfy 
mission objectives. In most cases, this first 
version is written by the office funding the 
mission for attachment to requests for study 
proposals. Its purpose is to provide 
information from which a contracting company 
or university can proceed to develop science 
requirements, mission requirements and the 
operations design requirements that support 
them. At this stage, the contents are the 
objectives and constraints of both the mission 
and individual experiments, and the conceptual 
approaches to operations system activities. 
Once determined and agreed upon by the 
participants, the operational approaches that 
constitute this initial concept should be placed 
under configuration control. They cannot be 


arbitrarily changed without the consent of all 
affected parties. This initial concept is a major 
source of operations design requirements 
generated as an input to the functional 
requirements documents. 

Once the initial set of MOS design requirements 
are defined, the first version of a full Opera- 
tions Concept document can be written and 
reviewed at the PCR. Figure 3 provides a 
sample outline for the content of this complete 
document, taken largely from Ref 2 with mod- 
ifications. Although it is likely to have many 
incomplete sections for those areas where 
detail is dependent on a design selection, it will 
contain the basic concept for operating the 
system as it is initially envisioned. It will 
define at a high level the intended uplink 
process for planning, scheduling, generating, 
validating, and transmitting commands or 
sequences of commands, and the downlink 
process for receiving, monitoring, separating, 
and processing the telemetry. These strategies 
are not final at this stage but will evolve with 
the design. 

In order to efficiently implement an Operations 
Concept, several ground rules need to be 
imposed during development. Adherence to 
these rules could make the difference between 
success and failure of the Operations Concept as 
a useful tool. 

f 1. Obtain early agree- 
ment on basic operational 
approaches. It is more im- 
portant that all the players 
agree on an approach, even 
if operationally less-than- 
optimal, than to have a 
perfect approach. 

2. Keep the document 
concise yet comprehensive. It 
should be a summary of 
intended operations. It must 
cover all areas of operations 
necessary to accomplish the 
mission, but restricting 
details in each area to that 
essential to conveying the 
message. 

3. Keep it updated. 
Revisions or additions, 
scheduled after major steps in 
the planning , design and 



Figure 2 - Operations Planning And Development Flow 
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1. Introduction 
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Activity Table and Timelines 
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6. Contingency Operations 

7. Operational Interfaces 
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Human-Computer Interfaces 

8. Operational Hardware Features 
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Special Facility Requirements 

9. Personnel Component 
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Organization and Support Coverage 
Training Concept 

10. Reliability, Maintainability and Availability 
System Reliability and Availability 
Maintenance and Logistics Concepts 

Figure 3 - Concept Document Content 

implementation processes, are essential. To be 
useful, it must be current. The design team will 
ignore an obviously out-of-date Concept. Up- 
dates released at each major review in Figure 1 
would be prefered. 

4. Let it evolve with the design. Although 
the concept will levy operations requirements 
on the design, the concept should be allowed to 
change (configuration controlled) if the design 
effort indicates more efficient or less costly 
ways of implementing the requirements. In 
some cases, the requirements themselves may 
also evolve with the program. 

5. Keep its focus user-oriented. The focus 
must be on the eventual operation of the MOS to 
achieve desired mission objectives, and on the 
users that must operate it. 

4. REQUIREMENTS AND 
DOCUMENTATION. 

In most programs, the definition of the initial 
operations concept usually occurs in parallel 
with the formulation of top-level mission and 
science requirements that will later govern the 
design. The Operations Concept, while not a 
requirements document per se, must be translat- 
ed into requirements specifications that will 
implement the desired concept. Requirements 
specifications are essential to establishing a 


common understanding between customer and 
contractor as to what the task must include and 
what the job must accomplish. Agreement on 
the requirements before proceeding to design is 
critical to efficient, cost effective, and on-time 
development of a system that will meet the 
customer’s needs. In addition, requirements 
documents provide a source of test objectives for 
the program test phase as well as providing a 
valuable archival reference during the remain- 
der of the program. For these reasons, the 
Operations Concept developer must understand 
the various types of requirements that are 
levied both on spacecraft design and on a MOS. 

Mission requirements are high level statements 
of the goals and objectives of the mission itself, 
or in other words, what it is that the mission is 
required to achieve. Mission requirements may 
reflect such issues as the type of orbit necessary, 
the mission duration to achieve the objectives, 
number of spacecraft contacts per day, and/ or 
spacecraft pointing accuracy. 

Parallel to these are the science requirements, 
which define the goals and objectives of the 
science experiments, in many cases further 
delineating the mission requirements. 

Examples of these are specifications of the 
target characteristics to sense, the resolution of 
the data to be obtained and the frequency range 
of an instrument. 

Operations requirements are MOS design 
requirements relating specifically to the ways 
of achieving the operational mission. In 
general, they define the scope of the ground 
activities within the MOS. They specify issues 
such as the number and type of ground antennas 
for spacecraft contact, the necessity for around- 
the-clock monitoring of vehicle activities, the 
types of computational activities that must 
occur, how experimenters will gain access to 
their data, and whether or not command 
sequences are validated with a simulator. At 
this level, the ground system can be treated as a 
series of black boxes, where the operations 
requirements define the functionality of the box 
(what it needs to do) and its interfaces with 
other boxes, but do not delve into the details of 
how the correct product is achieved. However, 
to design the black boxes, each operations 
requirement must be decomposed into one or 
more functional requirements. 
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Functional requirements are 
those that govern the design of 
the system components (to satis- 
fy science, mission, or operations 
requirements) by identifying 
the specifications for each 
function the component must 
accomplish. The primary 
emphasis of functional require- 
ments is on how the system is 
implemented rather than what 
the component does or the con- 
tent of its operational product. 

Lastly, performance require- 
ments are those which specify 
when functions or activities 
must be completed, how fast and 
their duration. They delineate 
the order in which tasks must be 
performed, the amount of time 



Figure 4 - Typical Document Tree 


allowed for an activity to be 
accomplished, other activity milestones that 
must preceed or follow given activities, and 
resource constraints imposed, especially when 
computer operations are involved. 


configuration documents or users guides. For the 
teams, the FRDs are followed by operations 
plans and procedures. 

5. SUMMARY. 


Figure 4 is a document tree for a typical space- 
craft mission operations system. Not all of 
these documents are required for every project, 
nor are all the documents shown that a given 
project may need. Those documents on the far 
right are those developed during the design 
and build of the spacecraft but which are 
essential to retain and to maintain during 
operations. They do not fit specifically into a 
MOS document tree, but instead supplement it. 
To the left are those documents that are devel- 
oped with the operations phase of the mission 
in mind, although they may be written very 
early in the life of the project. Along with the 
initial concept of operations, both the mission 
requirements and the science requirements are 
derived. The MOS Design Requirements docu- 
ment specifies how the mission and science 
requirements are converted to operations 
requirements to achieve implementation of the 
spacecraft operations activity. These, in turn, 
are decomposed into the functional require- 
ments which are recorded in FRDs for both 
team activities and for the ground data system. 
For the latter, functional requirements docu- 
ments are followed by hardware and software 
requirements and design documents and either 


This paper has defined an Operations Concept 
as a part of a structured process for design and 
development of a mission operations system 
(MOS). It has discussed the program phases, 
required reviews and documentation necessary 
to achieve a complete, efficient and cost- 
effective MOS. It emphasized the importance 
of the Operations Concept, written early and 
maintained, and stressed the need for complete 
definition and agreement on requirements before 
the design has proceeded too far to easily 
modify. In short, a well-written, complete and 
maintained Operations Concept document will 
contribute significantly to a well-designed, 
efficient and cost-effective MOS. 
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